Intellectual Productivity of Engineers: A Summary of Reactions Part 2

Lecture given.

In "The Engineer's Guide to Intellectual Production," there is something like, "When you feel like you're not having a hard time learning something new, it's because it's not really new," which is similar to the often quoted quote in the startup community, "When everything seems under control, you're just not getting out as fast as you should. This is a common quote in startup circles.

I think the context was that if you don't challenge yourself to learn more new things, you can't call it intellectual production (my interpretation).

When you are learning a "new language" that you can use without difficulty, (omitted) you are learning few new concepts. （This is a bad mentality to be stuck in and you need to realize it and get out of it.

The speed-reading story made sense to me, and I'm going to try the KJ method. The talk about excellence was also interesting.

What I wanted to remember.

How to know if knowledge has been built up

Can you explain in your own words?

Can you give specific examples that followed your experience?

Can I use that knowledge to achieve my goals?

People who are unmotivated are not able to focus on a single task.

To be able to do more than you can do today, "It's up to the barrel of your thought.

When you think you are learning, but you only know as much as you can, you are not learning (from "The Intellectual Production Techniques of Engineers"). The learning starts when you get stuck and don't know what you don't know.

The part about management strategy really stuck with me. I am strong in network protocols, and I know a little bit about GPUs, automated driving, and deep learning, so I would like to differentiate myself by combining them.

It was an easy read with a good balance of abstract and concrete stories.

Most of what I hadn't been able to verbalize was written in an organized manner, and I realized a lot...

I also appreciate that the citation information is well documented in the annotations!

The "crossing the border" of the Kaizen Journey and the "excellence" of Chapter 7 of The Engineer's Guide to Intellectual Production are similar.

I'm glad I read about the intellectual production of engineers!

Chapter 4 was written in a way that organized what I usually think about, so I felt so much clearer!

I also recommend a book called "An Engineer's Intellectual Production Technique" by NISHIO Hirokazu on how to organize information using cards. (This guy does it with "fusen.")

It is originally Jiro Kawakita's KJ method, but it is very easy to understand because he actually practices output to the point of putting ideas together and writing a book.

https://gyazo.com/629f3a385f2b1f211d83da5d438b8478

I found the second half difficult.

This book made me realize how much I usually don't think about anything. Let's start by writing down on paper the deadlines and goals of what we want to do.

Right now I am reading "The Intellectual Production of Engineers". I would like to send it to my past self in a time machine to read it, but even if my younger self reads it, he would not understand it due to lack of experience, and would be in a state of piling up boxes in the sky, which was the metaphor of the book.... I felt this dilemma. I felt something similar when I read the refactoring book.

I am currently reading "Intellectual Production for Engineers" and "Output Compendium".

Both have many points in common, but they are written from different perspectives, so it is good to be able to read them while comparing them.

https://gyazo.com/920dfceb1b882548c7d4ea011fb9c3ff

I've started reading "The Engineer's Guide to Intellectual Production." In my Scrapbox, "abstraction" and "KJ method" were already linked words, but I'm excited to see that the link will be further strengthened.

Using the KJ method to write down your thoughts is a good exercise in going back and forth between the concrete and the abstract.

I've been using it ever since I read The Engineer's Guide to Intellectual Production.

The book is a compressed version of work techniques often seen in business books, arranged in a style for engineers. The book addresses common problems such as "how to be motivated," "how to remember for a long time," and "how to read efficiently," and incorporates physiological/psychological aspects into methods that can be practiced on a daily basis.

I think I like that kind of thing because I generally find stories that explain or hack the behavior of the human body or groups of people in a hardware/software abstraction interesting.

I really like the nonsensical stuff like "Nmsec is the limit of the eye's afterimage recognition, and the pace of reading aloud is Nsec, so the pace of reading is in the range of N to Msec. On the practical side, I think the Pomodoro method of dividing task time is pretty useful.

What was unconscious is being verbalized anyway.

Does the math department need to understand one page at a time to move on? ..... I had one line when I was there, and as soon as I was unclear on even one line, the professor would... I stopped, so I went looking for books to understand the essence of the subject and kept my notes at 1~2 pages per line. So I didn't finish reading one book even in a year.

The SECI Model. Scrum as an intelligent creation system.

I'm reminded of what I read at the beginning of the year in "The Intellectual Production of Engineers." That one is individual play, this one is team play.

I collected about 100 contents for jjug ccc according to the list of 100 anyway in "The Art of Intellectual Production of Engineers".

It was not a how-to on engineering, but rather how to leverage the nature of engineering to become stronger. The talk about excellence based on differentiation strategy, etc., stuck with me personally. I want to put it into practice.

The Intellectual Production of Engineers, interesting 🙂 I feel like what I've been feeling in the atmosphere is falling into my stomach in writing. I see what you mean about flow theory! I thought. When I'm anxious or bored, I'll review the challenge 😌.

Chapter 4 of "The Intellectual Production of Engineers," How to Read a Book. It had the biggest impact on me. I have not read many books of this type, so I subconsciously read aloud quietly, and I was concerned about reading through the book, but now I feel that I don't have to do that. I knew this was a book I wanted to send to myself 10 years ago.

Chapter 3 of "The Engineer's Guide to Intellectual Production," the importance of the output needed to remember. It was kind of a rule of thumb, but I still remember things better once I write them down. Even if I don't have confidence in my memory, I can remember how to deal with technical problems that I used to write about in my old blog (which I don't use anymore).

In "The Intellectual Production Techniques of Engineers," there is a phrase, "Use knowledge to gain a position, and then use that position to acquire knowledge." I would like to use my position as a CSS framework world ranker to connect with various people and absorb various things!

I found myself reading The Intellectual Production of Engineers. I'll read it five more times.

I bought a copy of "The Engineer's Art of Intellectual Production," and flipping through it, I found that it explains various things related to intellectual production in a considerable volume, and the illustrations are easy to understand. I think Maruzen in Marunouchi has been pushing the book for almost half a year, and the fact that it has been on the shelves for that long suggests that it must be a big seller. Even non-engineers should read this book.

Role as a map for those who will be doing intellectual production

When choosing a reference book, you should look at the syllabus of the university. However, the author says that he excludes those by the lecturers themselves or those related to the university.

It was good to realize that I had incorrectly remembered how to do the KJ method.

Let's do sutra copying now and then. According to "The Engineer's Art of Intellectual Productivity," modeling is advanced by discovering similarities and differences.

I read "The Intellectual Production Techniques of Engineers," and Yuji Maeda said the exact same thing about how he writes his notes.

The flow of "concrete -> abstract -> applied" can be applied to all studies, not just program studies, and I think it is so important to be aware of this process when learning something.

I quite like the idea of the "straw man strategy" of learning new things using your current weapons as bait. The book: The Intellectual Production of Engineers also talked about the same thing with the term "serial specialist" - I think.

I'm vaguely aware of these places in a corner of my mind (but I haven't done anything about it lol).

I used to use the Pomodoro Technique only for study breaks, but when I read about the intellectual production techniques of engineers and applied it to my work, I had 7 Pomodoro in one day.

Surprisingly, tasks cannot be processed in a day.

By the way, I had finished reading "The Intellectual Production of Engineers". There were a number of passages that I was unsure about, and I wish I had read this earlier. The best part was "There is no 'story' in source code.

I read "The Technology Behind Coding" by NISHIO Hirokazu. I learned a lot. I would like to read this book again when I write programs in the future. I wish I had it when I was a student.

As I thought in "The Engineer's Art of Intellectual Production," I am glad that the author has managed to discard the details while carefully considering the order in which the topics are presented so that they can be easily absorbed into the mind. I also appreciate the back and forth between concretization and abstraction.

There are surprisingly few books like this that "create a rough map in your mind," which is valuable. Many of them are too dictionary-like and exhaustive, making it difficult for beginners to grasp the important points, and many of them do not touch on the purpose of various mechanisms and concepts.

I'm wondering if there's a pro-management version of the book "The Intellectual Productivity of Engineers." It's become the norm with Agile and Scrum in the last 20 years or so. A book that outlines techniques such as project charters, estimates are probabilities, decide on the done of tasks, combine buffers into one, don't move on to the next phase with a reverse line table, etc.

PMBOK is too much. It should be more like a how-to, introducing techniques and original sources. That would reach people who have not been exposed to Agile for 20 years.

---